NW-JAWS 勉強会#5レポート #NW_JAWS #jawsug

NW-JAWS 勉強会#5のレポートです。ネットワークの基本的な話から未来の話、そしてなかなか破天荒な話までバラエティ豊かな会でした！

#ネットワーク

#JAWS-UG

#勉強会

#レポート

#AWS

臼田佳祐

2019.09.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

NW-JAWS 勉強会#5 が開催されましたのでレポート致します。

NW-JAWS 勉強会#5

レポート

スポンサーセッション NTT東日本　スカイアーチ　エフセキュア

3分で紹介するF-SecureとSecurityと未来エフセキュアさん

[slideshare id=172950666&doc=20190917nw-jawsf-secure3min-190917095043]

資料はアップ済み
Securityで未来っぽいのは自動化
脆弱性診断を自動化していきたい皆様
パッチを適用していないLinux Serverに心当たりのあるみなさん
F-Secure Radarというツールがある
- 脆弱性診断できるよ
でかい事例もいっぱいあるよ
継続的、自動化脆弱性診断API連携で！
やり方はブログ参照！
そもそも使っているクラウド環境どこから診断したらいい？
サイバーセキュリティコンサルティングをご活用ください！
- ペアーズさんの事例もあります！

サーバ屋のサバカンの話しスカイアーチさん

どんな会社？
- ダジャレで鯖缶を配り始めた
- N-Comさんとトレンドさんのコラボ缶があった
- メディアにも露出しました！
- ナチュラルローソンにも出ました！
- 売上の38%を東北の子供支援に寄付しています！
- 買ってください！
- 10/2にイベントをやります！
  - 紹介者は「スカイアーチ岡田」と入れてください！

NTT東日本さん

サメのキグルミはAmazonで調べるとすごく高いらしい
ネットワークの会社というイメージですがクラウドもやってます！
閉域網もAWSの構築保守もある！
スムーズなクラウド導入のために円建て請求や導入運用プランなど拡充してます！
クラウド周りのサービスを総合的に提供
回線ももちろん様々提供しています
まずはお気軽にご相談ください！
WebでもOK

AWSの最新ネットワーク機能 AWS　yukihiro kikuchiさん

Transit Gateway / Shared VPC / PrivateLinkは話しません
レガシーなしってテーマだけどどうする？
新機能を紹介していく
リージョン展開
- 新規リージョンに香港とバーレーン追加
- 香港以降意図的にEnableにしないとリージョンが使えなくなった
Amazon VPC
- VPC Traffic Mirroring
  - ENIからミラーリング
  - pcapとれます
  - NLBに送ることが出来る
  - フォレンジックで利用できる
- VPCフローログにメタデータが追加
  - vpc-id, subnet-id等
ELB
- NLBがTLS終端対応
- NLBのUDPロードバランシング
  - DNS / SIP / SNMP等投げれる！
- NLBのSNI終端
  - 名前ベースで復数証明書登録可能
  - 最大25証明書まで(デフォルト証明書のぞく)
- Global AcceleratorでALBエンドポイントを対象にしたクライアントIPアドレス保存のサポートを開始
Direct Connect
- 新しいコンソール発表
  - グローバルの扱いになって1箇所で見れるように
- Direct Connect ゲートウェイのマルチアカウントサポート
  - 現時点では制約あり
    - 同一Payer、Organizations配下のアカウントのみ
- Transit GatewayのDirect Connect 連携
  - トランジット仮想インターフェースという概念が生まれた
    - サブ10Gというサービスが生まれている
    - 東京リージョンはしばらくお待ちを…
    - 皆さんの声で早くなるのでお近くのSAや営業にご相談を
VPN
- AWS Client VPN東京リージョンサポート
  - SSL-VPN
  - マネージドでつなぐことができます
- Site-to-Site VPNがIKEv2に対応
  - IKEv2しか対応していないクライアントでもOK
- Site-to-Site VPNにVPNトンネルのセキュリティアルゴリズム及びタイマー設定の環境設定機能を追加
  - 相性の悪い機器があった場合に調整可能
- Site-to-Site VPNで証明書に寄る認証のサポートを開始
  - ACMのプライベート証明書も利用可能
まとめ
- re:Invent以降のネットワークサービスを抜粋してご紹介しました
- Network Serviceは発展して行くので引き続きご愛用ください

感想

ネットワークだけでもいっぱいアップデートがあって嬉しいですね！

個人的には新しいリージョンがオプトアウトになっているのも嬉しいですね！

ネットワークがクラウドに載って変わることと変わらないことソラコム　大瀧さん

AZ IDのメソブログの人です
ネットワークがクラウドに載って
- 変わること
  - クラウドの特性
    - リソースが使い捨てできる
      - 失敗してもわりと大丈夫
    - スピード感、ハードルの低さ
    - 民主化、ノウハウの流通
      - 特定のベンダーに高い金を払わなくてもいい
      - みんなで情報交換できる
  - ネットワーク周り
    - ケーブリング不要
      - APIベース
    - 箱物の調達、納品、オンサイト対応不要
      - ※オフィス側などは別ですが
    - VPC、セキュリティグループの理解
      - 逆に必要なところ
      - 知識をアップデートしましょう
- 変わらないこと
  - ネットワーク
    - TCP/IP
    - 性能のボトルネック is still exist.
      - いくらスケールしてもEC2のスペックとかに依存したりする
    - コンピュータ/機器は悪くない
  - 全体として言えること
    - 使おうと思っているモノをよく知ること
      - クラウドもITの要素の一つ
    - 万能ではない
      - 機能はいっぱいある
      - 用途に合わせて使い分けが大事
変わらないけど広がること
- ネットワーク仮想化
  - AWSだとAmazon VPC
    - L2L3の機能諸々
仮想ネットワークは与えられるもの？
- 出てきた機能をフォローするのが活用なのですか？
- 否。ユーザも仮想ネットワークを作れる
- それがSORACOM
ネットワーク仮想化のススメ
- SORACOMの紹介
  - IoTの民主化
  - モノ向け通信のサービスSORACOM Air for セルラー
  - Amazon経由でSIMを買える
  - 事例: ソースネクスト様のPOCKETALK
  - あゆみ
    - 2015年にサービス提供
    - 2017年にグローバルSIM提供
    - 2019年には100万回線突破
- SORACOMのしくみ
  - モバイルコアなどをAWS上に作りました
  - SIMが刺さったデバイスからはSORACOMを経由してインターネットに出る
  - APIで操作できる
    - 回線止めたり、速度を変えたり
  - インターネットに出る前に通信へ介在できる
- SORACOM Napter
  - 通常SIMに渡るIPはプライベートIP
  - NATする
  - 外からは入れない
  - オンデマンドなリモートアクセスをNapterが提供
  - ポートフォワーディングのマネージドサービス
  - 期限付き
    - 消し忘れすることがない
  - TLS
- SORACOM VPG
  - ユーザ専用のGateway
  - デバイス間通信の禁止/許可設定可能
  - 物理的に離れているデバイスでも関係なく通信制御可能
  - VPCへのプライベート接続
  - 何がいいのか
    - 一般的なモバイルインターネット接続のネットワークモデルではSIMから外がWAN
    - SORACOM VPGだとVPGまでは閉域LANとして設計できる
  - VPGデバイスサブネットの活用
    - eDRXを利用するといいらしい
    - 詳細はブログで
  - SORACOMに見る仮想ネットワークサービスの可能性
    - SORACOMに限らず新しいネットワークモデルはまだたくさんできるはず！
まとめ
- ネットワークがクラウドに載ることでネットワークエンジニアはスケールする
- 仮想ネットワークはクラウドとクライアントの境界を曖昧にする
hiringしてます！

感想

SORACOMのネットワークはとてもユニークで面白いですね！

新しいネットワークモデルを考えついたらぜひやってみましょう！

世界のネットワーク事業者の最新AWSサービス動向と今後の予想 NTTコミュニケーションズ　林さん

AWSとNTT Comの関係
- サーバーワークスとの資本提携
- Amazonなどと海底ケーブル建設
- NTT Com Forumでもなにかやります
クラウドのトラフィック
- クラウドのトラフィックが増えている
- DC間も特に増えていく
- 上位5社にNTT Com入っている
- 世界のマーケットでもAWSと通信事業者の連携が強化されている
だんだん境界線が曖昧になってきた
- いい呼び名はないか？
- AI Defined Infrastructureとかも出てきている

ネットワーク事業者のAWS接続サービス動向

ユーザを取り巻くIT環境の変化
- 昔はシンプルだった
- 昨今はIaaSでもリージョンが別れたり、SaaSもあったりで複雑
- ネットワークへの普遍的な要求
  - 安く
  - 早く簡単に
  - うまく(品質)
  - 品質はやはり重要
  - ネットワークの想定外のトラブルはアプリでの回避難しい
    - 冗長化や分散しても最後はネットワーク
ネットワーク事業者のAWS接続サービス
- 早く安く簡単に
  - クラウド接続の超簡単モデル
    - BGP設定してNW機器で接続
  - 時間とお金がかかるのは
    - 物理回線引き込みやキャリアへのオーダ
    - 帯域確保
    - ルータの設定、BGP、対抗との調整、接続要件の理解
  - これらに対してのキャリアサービス
- キャリアサービスとしての安く早く簡単に
  - 物理はしっかりと最適な場所に事前配備
  - 物理設備を必要なユーザ様同士で共有することで費用削減
  - ソフトウェア技術の適用(SD化)によるサービス提供の迅速化
  - 各種設定のAPI(SD)化
- うまく(品質)
  - お客様の要望はいくつかある
  - インターネットだけの場合もあれば、インターネットVPN、閉域網等
  - インターネットだと遅延がばらつく
  - 閉域網は安定したスループットが出る
  - 経路ハイジャックも閉域網では安心
  - DDoSにも閉域網は強い
  - うまいとは
    - どっちがいいかはユーザが求めるもの次第
    - 双方どんどん美味しくなってきているが違うものであることは理解する必要がある
まとめ
- ネットワーク事業者も早く安くうまいを求めて新しいチャレンジをし続けます
- ネットワークでは想定される品質が安定提供されることが非常に重要
- ビジネス上の要件をしっかり理解した上で最適なシステムを一緒に作っていきましょう

感想

改めて物理の大切さを感じますね。

クラウドになってもネットワークの品質を意識して使いたいですね。

Amazon EC2で100 GbE がリリースされたので試してみたスカイアーチ　福島さん

Motivation(動機)
- 昨年のre:Invent 2018で発表された
- これまではMS Azureの40Gが最高だった
- おーすげーと思った、が本当に出るのかとも思った
- オライリーの本では10GbEもなかなか使えないという話があった
- ボトルネックになることは無いか？
- USEメソッド
  - Utilization
  - Saturation
  - Errors
- 今回はあえて飽和させる必要がある
- 例えばメモリ
  - DDR4-2666だとだいたいチャンネルあたり170Gbps
- 例えばCPU
  - MTU9001だとざっくり150万パケット
  - 0.67usで1パケット処理する必要がある
  - 3GHzだと2000サイクル程度で処理する必要がある
- 利用できるインスタンスタイプ
  - c5n.18xlarge
  - p3dn.24xlarge
  - i3en.24xlarge
  - あたり
- 気になるお値段は？
  - c5n.18xlargeが一番安いが4.896USD/時間
  - 対向で2−3時間使って大体新橋のサウナ1回分くらいなのでそれならお小遣いでなんとかなりそう
  - でも値落ちしてちょっと使いすぎましたｗ
- 実機を買うと100万円以上の出費
やってみよう
- 環境
  - 東京より若干安いオレゴンで
  - us-west-2b単一
  - c5n.18xlarge
  - Amazon Linux2
  - iperf3
  - MTU 9001
- 1プロセス-Pで測定
  - 25Gbpsくらいで頭打ち
  - 性能情報確認
    - 特定CPUで100%
    - CPUの性能限界と思われる
  - そもそもiperf3は単一プロセス/スレッドで多重化しているので処理が特定CPUに偏る
- 仕方がないので復数プロセス利用
- RSSが有効になっているように見受けられるので復数プロセッサでの処理がおそらく効果的なはず
- キャッシュの有効利用という観点からもプロセッサ毎分割がいいはず
- c5n.18xlargeはCPUありすぎて大変
- 実測値
  - 大体20プロセスくらいでほぼ100Gbps位でた
  - 結構トラフィックはばらつく
  - が、80以上は出る
- おそらくウインドウスケールや流量調整・輻輳制御などの関係でTCPが帯域を使い切らないように程よく調整しているためと思われる
- また、ソケットが協調して服装s帝ぎょしているわけではないのでそれぞれが個別に計算した結果一斉に流量調整すると全体としてスループットが下がる可能性がある
- 厳密にはパケットキャプチャを採取して確認する必要があるがしんどい
- AWSにはPlacement Group
  - クラスタープレイスメントグループでは各インスタンスを近い場所において低レイテンシにできる
  - シングルフローで10Gbps
  - これを使ったら安定するかと思ったがジグザグした
  - 安定しない
  - 今回のように連続してバースト転送するようなユースケースでは低レイテンシのメリットを享受できなかった
まとめ
- 高速ネットワークを使用する場合はマルチプロセスマルチスレッド
- TCPを複数ストリームへ分散する場合には注意が必要
- プロセッサ数や通信可能帯域が増えたので異なる調査手法、表現方法が必要
- プロエッサカウンタやbccなど利用可能な仕様及びツールが増えてきているのでこれらを有効に利用してより良い的確な分析ができるようにしたい